Method for overload control in a telecommunications network and apparatus therefor

ABSTRACT

A method of suppressing overload in a telecommunications network involves the second node (1) receiving a signal that calls it has sent to a target node are being rejected and (2) reducing the rate of calls it sends to the target node in response.  
     The network could be a UMTS or other third generation ( 36 ) network.

CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority of Great Britain Application No.0110155.9 filed on Apr. 25, 2001.

FIELD OF THE INVENTION

[0002] The present invention relates to a method for overload control ina telecommunications network. The present invention also relates toapparatus therefor.

[0003] The network can be a UMTS or other third generation (3G) network.

BACKGROUND OF THE INVENTION

[0004] Calling rate patterns in telecommunication networks typicallyhave predictable daily profiles with occasional very high peakssuperimposed. These peaks can be caused by events such as telephonevoting due to a television program, or disasters, etc.

[0005] Although it would be possible to dimension a network to handlesuch peak traffic, it would be uneconomic to do so. In addition, masscall events frequently have several source nodes, but are focussed on afew, or just one, destination, and will overload it. Networkdimensioning cannot solve a destination's overload, and some form ofoverload control is required to manage peak traffic.

[0006] Many mass call events are unexpected, so the control needs to beautomatic. Overloads often increase rapidly (within seconds in somecases), persist for minutes with large fluctuations in amplitude, anddissipate over a somewhat longer period. This means that the controlneeds to be fast in application, and be able to adapt readily tochanging loads.

[0007] Ideally, the nodes whose callers caused the overload event shouldexert control, since they have the possibility of informing thesecallers of the situation. However, the target node for the overloadneeds to be able to control its input until the sources have time toreact. Here, actions by the target node are referred-to as “localoverload control”. The target node often does the minimum work necessaryupon calls to control its local overload, in order to protect itself inthe short term. Such local overload control has the danger that, ifcallers are not told promptly of the overload, they will reattempt theircalls. This could cause the overload to spread through the network.

[0008] Hence, network signalling systems such as InternationalTelecommunications Union ITU-T Signalling System No.7 (SS No.7) havedefined as part of their protocol messages and procedures to be used bya target node to inform its adjacent source nodes when it is inoverload. SS No.7 has defined an “automatic congestion control” (ACC)procedure and an “automatic congestion level” (ACL) parameter to be usedin all call release messages by an overloaded node. The ACL parameterhas one of two possible values “less severe” or “more severe”, but themeaning of these values at the target node is not further defined. Thebehaviour of the target node is also not defined.

[0009] Source nodes are expected to reduce their traffic towards theoverloaded node when they receive a release message containing an ACLparameter from it, and if possible they inform their local callers ofthe situation. Such attempted restriction of traffic towards a remotenode is called “remote overload control” here. The speed at whichtraffic can be reduced, and the degree of reduction is not defined in SSNo.7, but they depend upon the traffic level, the implementation of thesource and target nodes, and the network.

[0010] In order to reduce the amount of call re-attempts, the trafficoffered by sources to the target node should be held close to,preferably just under, the capacity of the target node. This ensures itsoptimum performance during emergencies.

[0011] The work performed by source nodes in remote overload controlshould not cause the source itself to be come overloaded.

[0012] Many solutions for remote overload control in SS No.7 maintain anoverload level indication for a remote target node, the indicationdepends upon the value of the ACL parameter received, and frequentlyupon the rate at which release messages containing ACL parameters arereceived from it. A timer is started at the reception of the firstrelease message containing an ACL parameter, which is restarted if sucha release message is received before the timer expires. The overloadlevel indication is increased upon reception of a release messagecontaining an ACL parameter, and decreased if the timer expires. Whenthe indicated overload level reaches zero, traffic restriction isstopped.

[0013] Some solutions limit the speed at which the overload levelindication can be increased, by use of a short guard timer which isstarted upon reception of the first release message containing an ACLparameter. Further such release messages received whilst the short timeris running are ignored in the remote overload control procedure. Receiptof a release message containing an ACL parameter when the short timer isnot running, whilst the long timer is running, cause the short timer tobe restarted, the long timer to be restarted, and the overloadindication to be updated.

[0014] Some solutions for remote overload control use a form ofproportional reduction of traffic offered to the sources for the targetnode, the proportion depending upon the indicated overload level. Othersolutions use some form of rate limiting mechanism, such as a leakybucket, the rate of calls offered by the source node to the targetdepending upon the indicated overload level. Rate limiting schemes arebetter than proportional discard schemes in that they limit absolutelythe traffic offered to the target node.

[0015] It is known from U.S. Pat. No. 5,450,483 to provide a ratelimiting scheme using a leaky bucket in source nodes, whose rate is setby another leaky bucket there recording the rate at which call rejectsare received from the overloaded target node. This requires the targetto be kept just over its overload level. It uses the ISDN User Part ACCmechanism (described in ITU-T Recommendation Q.764 (09/97) section2.11).

[0016] It is known from International patent application WO99/38341 toprovide a scheme which uses a continuous “overload control level” (OCL),whose value is set by receipt of call rejects as in Q.764 section 2.11,against calls released normally. The OCL value determines whatproportion of calls offered to the source for the target will bediscarded. It is not an absolute rate limiting scheme.

[0017] Each known remote overload control method has its ownlimitations. Methods using an overload indication level at the sourcenode tend to impose an initial traffic restriction at the minimumdiscrete level, the restriction increases with further overloadindications. If the onset of overload is rapid, and the offered trafficis high, the initial restriction level tends to be so low that thetarget is pushed into an overload state from which it can recover onlyby extreme measures such as message discard.

[0018] With a discrete number of overload levels, in order to get asmooth response the number of levels tends to be high. This causes aslow response to sudden overload. In addition, the response by thesource to removal of the overload tends to be slow, and the trafficoffered to the target by the source tends to drop significantly there.

[0019] If the restriction method is to discard a proportion of theoffered traffic according to the overload indication, a severe trafficoverload offered to the source can result in a severe traffic overloadoffered by the source to the target.

[0020] The method described in U.S. Pat. No. 5,450,483 mentioned aboverequires the target node to be kept just over its overload level. If thetarget node employs any technique such as discard of some call set upmessages, or delays rejection of them to reduce the possibility ofreattempt by the caller, the apparent overload level recorded need notbe the actual overload level, and the behaviour of the network might bedifferent from that expected. In addition, the efficiency of the targetis reduced by its need to reject calls.

[0021] The method described in WO99/38341 mentioned above requires a mixof release messages with and without ACL parameters to fix the OCLvalue. It uses a proportional discard scheme, and hence is liable to beslow in reacting to a rapid overload. In addition, some types of call(e.g. those which originate in the public switched telephone network anddestined to the Internet) are cleared down in normal circumstances onlyby the caller. Consequently, a switch used to connect to the Internetwill clear down calls only when overloaded, and so would normally notsend a release message without an ACL parameter. Thus a source localexchange using this method for remote overload control sending calls toa once overloaded Internet-connected switch will assume it is stilloverloaded.

[0022] Other known methods have a serious weakness, which is caused byuse of a timer to reduce restriction to the target node. Overloads canbe of any duration, if expiry of a timer causes the restriction to belifted or even just decreased at the source, with the traffic offered tothe source for the target still greater than the target's capacity, thetarget will enter overload again. During long duration periods of highoffered traffic, the target thus oscillates into and out of overload.

SUMMARY OF THE INVENTION

[0023] The present invention provides a method of suppressing overloadof a first node in a telecommunications network by the steps of a secondnode: receiving a signal indicating that a call directed from the secondnode to the first node has been rejected and in response restricting therate of transmission of calls from the second node to the first node toa predetermined level, and monitoring duration through a predeterminedtime period wherein if a further signal indicating that a call directedfrom the second node to the first node is received during thepredetermined time period, the rate of transmission of calls from thesecond node to the first is restricted further to a further reducedpredetermined level and duration through a further predetermined periodis monitored.

[0024] The preferred methods react quickly to a sudden onset ofoverload, they both keep the target just under overload during theduration of high offered traffic at the source. They do not allow thetarget to oscillate into and out of overload. Variations of load offeredto the source node for the target, above the target's capacity, arefiltered out by the source node.

[0025] Preferably the or each predetermined level of restriction isselected dependent upon the measured rate of calls (D_(measured)) fromthe second node accepted by the first node.

[0026] As the level of restriction (“leaky bucket” rate) is determinedby the measured capacity of the target node, any changes to thatcapacity cause the leaky bucket rate to change. Thus modifications tothe software or hardware at the target node which cause its capacity tochange are automatically catered—for, they do not need managementintervention at the source. Management intervention at the source isalso not required if there is a change in the number of other sources inthe network.

[0027] Preferably the steps of restricting and monitoring are repeateduntil no signal indicating that a call directed from the second node tothe first node has been rejected is received during the latestpredetermined period.

[0028] The source nodes do not need to communicate with each other inorder to jointly control overload at a target node.

[0029] The present invention also provides a telecommunications networkcomprising a first node and a second node, the second node comprisingreceiving means operative to receive a signal indicating that a calldirected from the second node to the first node has been rejected, andrestricting means operative in response to both restrict the rate oftransmission of calls from the second node to the first node to apredetermined level and start its timer to monitor duration through apredetermined period, wherein, in use, if a further signal indicatingthat a call directed from the second node is received by the receivingmeans during the predetermined period being measured by the timer, therestricting means reduces the rate of transmission of calls from thesecond node to the first node to a further predetermined level andrestarts the timer.

[0030] The present invention also provides a telecommunicationsapparatus comprising receiving means operative to receive a signalindicating that a call sent from said apparatus has been rejected, theapparatus comprising restricting means operative in response to restrictthe rate of calls sent out and start its timer to monitor durationthrough a predetermined period, wherein in use, if a further signalindicating that a call sent from said apparatus has been rejected isreceived by said receiving means during the predetermined periodmeasured by the timer, the restricting means further reduces the rate ofcalls sent out.

[0031] The preferred methods are not limited to remote overload controlby one node of one other in a telecommunications network. Each sourcenode can monitor all target nodes with which it was concerned, so thatif any overload of any target occurs, the associated source nodes canthen perform the corrective action of automatic congestion control.

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] A preferred embodiment of the present invention will now bedescribed by way of example and with reference to the Figures in which:

[0033]FIG. 1 is a diagram illustrating a telecommunications network inwhich overload control is undertaken,

[0034]FIG. 2 is a diagram illustrating a network for which the behaviourwas determined, using methods for overload control according to thepresent invention,

[0035]FIG. 3 is a graph showing levels of calls offered to sourceexchanges and target exchange in the network shown in FIG. 2 with thefirst preferred method of congestion control,

[0036]FIG. 4 is a graph showing levels of calls admitted to the targetexchange in the network shown in FIG. 2 with the first preferred methodof congestion control,

[0037]FIG. 5 is a graph showing levels of calls offered to sourceexchanges and target exchange in the network shown in FIG. 2 with thesecond preferred method of congestion control,

[0038]FIG. 6 is a graph showing levels of calls admitted to the targetexchange in the network shown in FIG. 2 with the second preferred methodof congestion control,

DETAILED DESCRIPTION

[0039] Two preferred methods of automatic congestion control (ACC) willnow be described, specifically two Remote Overload Control methods forSS No.7 ISDN User Part (ISUP), i.e. methods for overload control at asource exchange. The two methods are both adaptive rate based automaticcongestion control (ACC) schemes satisfying the requirements of therelevant standards. Both first and second methods automatically adjustfor short and long term variations in target exchange capacity duringoverload. Short term variations can occur because of the nature of theoverload traffic itself, long term variations can occur, for example,because of software or hardware changes at the target exchange, orchanges in the number or size of source exchanges in the network.

[0040] The first method requires continual measurements of calling ratesboth offered by the source exchange to the target exchange, and rejectedby the target exchange from the source exchange. In order to lift theACC, measurement of calling rates offered to the source exchange for thetarget exchange are also required once ACC starts.

[0041] In the first preferred method, it is not essential to signal thefact of overload from target to source initially. Since the methodrequires source nodes to monitor the load offered them for the target,in an alternative a threshold is defined at which the target is deemedto be overloaded. Restriction of load is then applied. In thisalternative case, it would, of course, be advisable occasionally toraise the leaky bucket leak rate slightly in order to test the loadcondition of the target, any increase in call rejection rates from thetarget would then cause the leak rate to be adjusted down to the actualcapacity of the target, and the offered rate threshold could beadjusted.

[0042] The second method does not require measurements to start at thesource exchange until a remote exchange (the target exchange) declaresit is overloaded. An initial call restriction level is applied at thesource exchange, and call rate measurements are started. Oncemeasurements are sufficiently precise, the call restriction can bemodified. If a sufficiently long time elapses after the start ofoverload without the overloaded target exchange sending furtherindications, and before the traffic offered to the source for the targetis sufficiently low, the source decreases slightly the call restrictionlevel, in order to determine the maximum level for calls from the sourceto the target. The call restriction level applying just before cessationof the ACC is remembered, in order to apply it at a subsequent overloadof the remote (target) exchange.

[0043] The second method has the advantage that resources at sourcenodes are not required until a target reports overload. Thus storage canbe saved and performance enhanced. In order to cater for target nodecapacity increase between one overload event and another, a source nodeuses feedback to estimate target node capacity for calls from itself.This could put the target back into a temporary, but controlled,overload state.

[0044] First Method of Congestion Control

[0045] The first method uses a mechanism for each outgoing route in eachsource node, i.e. source exchange in the network. This continuallymeasures in each interval (usually 1 second) the call rate D_(measured)accepted by the route which does not cause overload at the target node.The measurement is smoothed with an exponential smoothing formula tocalculate D_(smooth).

[0046] The call rates are in units of accepted calls per second.D_(measured) is better taken to be the difference between the number ofcalls offered by the source to the route in the interval (i.e. for SSNo. 7 ISUP signalling the number of initial address messages (IAMs))minus the number of rejects from the route in the interval (as measuredby number of release (REL) messages with an ACL parameter), rather thanby the number of address complete messages received.

[0047] The calling rate O_(new) offered to the source for the targetnode is also measured in each interval, with a smoothed value held inO_(smooth).

[0048] D_(smooth) is used to determine the leak rate of a notional leakybucket used to restrict calls to the target node, should it be inoverload. O_(smooth) is used to determine when to lift the restriction.Initial values for D_(smooth) and O_(smooth) are set in the source nodein configurable data, determined by network and node dimensioning.

[0049] If a call is rejected with an ISUP REL message containing an ACLparameter and ACC is not active for the route, then ACC is activated forthe route. Timer T_(short) is started for the route. The overload statuslevel of the route is set to the value of the ACL parameter, 1 or 2 forITU-T ISUP.

[0050] Calls to the target are restricted by the source using a leakybucket whose rate is calculated using an exponential smoothing formulawith inputs the current leaky bucket rate L_(level), and D_(smooth). Aseparate leaky bucket rate and leaky bucket size are used for level 1and level 2, their initial values being set in configurable date in thesource, and determined by network and node dimensioning. (The bucketsize, of course, determines what variability in call rates offered tothe source exchanges is allowed). The leak rate for the level 2 leakybucket is set lower than that of the level 1 bucket to enable a sharperreduction in traffic.

[0051] Calls rejected by the target during T_(short) are counted butotherwise ignored, except that a REL received during T_(short) with ACLparameter 2, when the current overload level for the route is 1, causeslevel to be set to 2. At the expiry of T_(short) a timer T_(long) isstarted for the node. T_(short) is typically 600 ms, T_(long) istypically 12 seconds.

[0052] If, during a measurement interval when a timer T_(short) is notrunning for a target node, that node rejects a call using a REL messagecontaining an ACL parameter with value greater than or equal to thecurrent held value of level, any timer T_(long) running for the targetnode is stopped, and a short timer T_(short) is started for the targetnode. L_(level) , is updated to the current value of D_(smooth).

[0053] If T_(long) expires with level=2, level is decremented andT_(long) is restarted. The leak rate for level 1 is not changed here.

[0054] If T_(long) expires with level=1, if O_(smooth)>L₁, where L₁, isthe current leak rate, T_(long) is restarted and neither level nor theleak rate is changed.

[0055] This check is to stop oscillation in overload at the target. Itensures that the ACC control is not lifted if the source still has toohigh an offered load for the target.

[0056] If O_(smooth) allows, level is set to 0, and restrictions to thetarget are removed.

[0057] The value of the leak rates for each value of level areremembered, to be used at a subsequent overload of the target node.Measurements of call rates are continued.

[0058] Second Method of Congestion Control

[0059] The second method differs from the first in that it startsmeasurements of the overloaded node's capacity only at the report ofoverload. It applies the stored value of the appropriate notional leakybucket's leak rate, this can then be modified after a time T_(short) ifnecessary. The initial value of L₁ is remembered by the source node inL_(init).

[0060] The value of T_(long) would normally be set to 6 seconds, ratherthan the 12 seconds of the first solution.

[0061] If T_(long) expires with level=1, if O_(smooth)>L₁, where L₁ isthe current leak rate, T_(long) is restarted and level is not changed,as in the first solution.

[0062] If O_(smooth)>L₁ when T_(long) expires with level=1, L₁ ischanged if it equals L_(init). Both are then set to

[0063] L_(init)=L₁=L₁×increase_factor, where increase_factor is aconfigurable parameter per route, typically 1.03. This “discovery”scheme allows an increase in the calling rate offered by the source tothe target, if the target has had an increase in available capacity.

[0064] If O_(smooth)≦L₁ when T_(long) expires with level=1, trafficrestriction and call capacity measurements are stopped for the target,but the values of L_(level), O_(smooth) and D_(smooth) are rememberedfor use at a subsequent overload there.

[0065] Implementation of the Two Methods

[0066] A high level diagrammatic view of how the overload controlfunctions interact in a network is given in FIG. 1.

[0067] The target exchange (T) which can be a trunk exchange includes anadmission control stage (A) which determines if a call should beadmitted or rejected. The admission process is used to drive adaptationof the level of call restriction applied at source exchanges (S) whichcan be local exchanges. Details of the target exchange's admissioncontrol stage (A) are not shown, as these relate to local overloaddetection and control and do not affect the remote overload controlmethods.

[0068] As shown in FIG. 1, each source exchange (S) has three functionalcomponents for remote overload control, labelled D, U and R in FIG. 1.It can be considered that there is one instance in the network of D, Uand R per traffic route per exchange. The functionality of the D, U andR components may be summarised as follows:

[0069] A detection and monitoring process (D) measures and smoothes theaccepted call rate of the target exchange's admission control (A),monitors the call reject rate of the route at each source exchange andmeasures the call rate offered to the source for the target. If callsare rejected, D informs U of the target's previously accepted call rate.

[0070] A restriction update process (U) updates the level of restrictionin response to the information received from D; restriction is increasedif the target is rejecting calls and its smoothed currently acceptedcall rate is lower than the currently offered call rate. Restriction isreduced if the smoothed currently accepted call rate is greater than thecurrently offered call rate.

[0071] A restriction process (R) thins the incoming demand stream basedon its current level of restriction. This restriction is applied afterany restriction due to other non-automatic Network Management controls.

[0072] In the first method of ACC, instances of D are always present,and run even when the target exchange is not overloaded. In the secondmethod of ACC, it can be considered that an instance of D is created andruns only when an exchange reports that it is in overload.

[0073] The functional stages D, U and R will now be described in moredetail, in each case the second method being considered before thefirst.

[0074] Detection and Monitoring Process D (Second ACC Method)

[0075] For each outgoing overloaded route, each source exchange containsan instance of the monitoring process D, which keeps a record of theroute capacity. This capacity is set up initially using configurabledata, the monitoring process updates this by measuring continually, onceremote overload has been reported, the call rate accepted by the routewhich, after the initial overload indication from the overloaded targetexchange, does not cause subsequent overload at the target. Themeasurement is smoothed using the formulaD_(smooth)=κD_(measured)+(1−κ).D_(smooth), where 0<κ<1 is a constantchosen from modelling according to the route characteristics. Normally,κ could be set to 0.2.

[0076] D_(smooth) and D_(measured) are in units of accepted calls persecond. D_(measured) is best taken to be the difference between thenumber of calls offered by the source to the route in the interval (i.e.for ISUP signalling the number of IAMs) minus the number of rejects fromthe route in the interval (as measured by number of REL messages withACLx), rather than by the number of address complete messages received.

[0077] The calling rate O_(new) offered to the source for the targetexchange is also measured, with a smoothed value held in O_(smooth).

[0078] O_(smooth)=β×O_(new)+(1−β)×O_(smooth), where βis normally 0.2

[0079] D_(smooth) is used to determine the leak rate of a leaky bucketused to regulate calls, by the restriction process R, to the targetexchange, should it be in overload. O_(smooth) is used to determine whento lift the ACC restriction.

[0080] If a call is rejected with an ISUP REL message containing an ACLparameter, and ACC is not active for the route, then ACC is activatedfor the route. Measurements are started for the calling rate offered tothe source for the target, for the calling rate the source offers to thetarget, and for the reject rate from the target. Timer T_(short) isstarted for the route. The overload status level of the route is set tothe value of the ACL parameter, 1 or 2 for ITU-T ISUP. The update andrestriction stages U and R for the route are informed of the value oflevel.

[0081] Calls rejected by the target during T_(short) are counted butotherwise ignored by D, except that a REL received during T_(short) withACL parameter 2, when the current overload level for the route is 1,causes level to be set to 2, and U to be informed. At the expiry ofT_(short) a timer T_(long) is started for the exchange.

[0082] T_(short) is typically 600 ms. T_(long) is typically 6 seconds.

[0083] If, after remote overload has been indicated and T_(short) is notrunning for a target exchange, that exchange rejects a call using a RELmessage containing an ACL parameter with value greater than or equal tothe current held value of level, any timer T_(long) running for thetarget exchange is stopped, and the restriction update process U isinformed of the value of level and D_(smooth). A short timer T_(short)is started for the target exchange.

[0084] If T_(long) expires with level=2, level is decremented. Therestriction update process U is informed of the value of level andD_(smooth), and T_(long) is restarted.

[0085] If T_(long) expires with level=1, a check is made forO_(smooth)>L1, where L₁ is the current leak rate. If this is so,T_(long) is restarted and level remains the same. U is informed so thatthe leak rate can be adjusted if appropriate.

[0086] If O_(smooth) allows, level is set to 0, and D informs U.

[0087] When level reaches 0, restrictions to the target are removed.

[0088] Detection and Monitoring Process D (First ACC Method)

[0089] The difference between the first and the second method is that inthe first method a source exchange continually measures each targetexchange's call acceptance level, whereas in the second method a sourceexchange starts measurements for an overloaded target exchange whenoverload is reported to it. In the first method the restriction updateprocess is informed of the value of D_(smooth) measured just beforeoverload starts, whereas in the second method the value of D_(smooth)used at the start of overload is the one remembered from the previousoverload (or, if this is the first overload, a configured value).

[0090] Restriction Update Process U (Second ACC Method)

[0091] Each source exchange contains an instance of U per overloadedroute.

[0092]

[0093] In each concerned source exchange, for each outgoing route whenits overload status changes, U notes the overload level and any value ofD_(smooth) reported by D for the target.

[0094] If the value of level is>0, U informs the restriction process R,and provides the leak rate for R to use. This rate is given byL_(level)=α×D_(smooth)+(1−α)×L_(level), where L_(level) is initiallyconfigured for the route by modelling and measurements. It is rememberedbetween overload incidents for each route. α is a parameter which is setto 0.5.

[0095] If the value of level is=0, U instructs R to stop restriction oftraffic to the target.

[0096] U remembers the leaky bucket rate to be used when overload isfirst reported, and stores it in L_(init) for comparison with the actualleaky bucket rate when T_(long) expires with level=1.

[0097] If the AC Control is to continue when T_(long) expires withlevel=1, L_(level) is changed if L_(level)=L_(init) to

L_(init)←L₁←L₁×increase_factor else if L_(init)>L_(level),L_(init)←L_(level).

[0098] increase_factor is a configurable parameter per route, typicallyslightly greater than one, for example 1.03. This allows an increase inthe calling rate offered by the source to the target, if the target hashad an increase in available capacity.

[0099] Restriction Update Process U (First ACC Method)

[0100] The differences between the first method and the second method isthat a source exchange using the second method needs instances of U onlyfor overloaded routes. A source using the first method might haveinactive instances of U for non-overloaded routes.

[0101] Restriction Process R (Second Method)

[0102] In each concerned source exchange, for each outgoing restrictedroute (i.e. the route's/target's level>0) R uses a leaky bucket tothrottle calls offered to the target. The bucket size is set to aconfigurable value per target, the leak rate is that re-computed by Ufor each remote overload status change.

[0103] Restriction Process R (First Method)

[0104] This is as for the second method.

[0105] Examples of Networks Using the Two Preferred Methods

[0106] The effect of the two proposed remote overload control adaptiveACC methods at the sources nodes (i.e.source telephone exchanges) wasdetermined for a network having the topology shown in FIG. 2. It wasassumed that there were 24 source exchanges supplying originating callsto the target exchange. The target exchange made use of up to n (usually8) Network Access Exchanges (NAS) to connect data paths through from thesource exchanges. SS No.7 signalling was assumed from source to targetexchange, with ACC being enabled in the target exchange. It was assumedthat the target was nominally able to accept 300 calls per secondwithout overload.

[0107] The background call rate offered to the sources for the targetwas assumed to be 300 calls per second from all 24 sources, with a stepat the 61^(st) second up to 1000 calls per second until the 121^(st)second, then 300 calls per second to the 181^(st) second, then 1000calls per second until the 241^(st) second, then 300 calls per second.For the runs, the call holding time mean was assumed to be 20 seconds,with a negative exponential distribution. Initially the combined totalbucket leak rate for all sources was 300 calls per second for thetarget's indicated ‘moderate’ overload level (level 1 corresponding toACL parameter value 1) and a bucket size of 10 calls, and 275 calls persecond for severe overload level (level 2 corresponding to ACL parametervalue 2) with a bucket size of 5 calls, but the actual rate per sourcewas assumed proportional to the source size. The timers were T_(short)600 ms, T_(long) 6 seconds for the sources. The signalling loop delayfrom target to source was assumed to be 18.5 ms for sources connected tothe active side of the target, and 19.5 ms for sources connected to thestandby side.

[0108] In both cases it was assumed that of the 24 sources, 12 sourceswere large and 12 sources were small, in the sense that the largesources handled six times as many calls as the small sources.

[0109] Based on the above mentioned values but with T_(long) set at 12seconds rather than 6, the results shown in FIGS. 3 and 4 were obtainedusing the first method of ACC described above. FIG. 3 shows callsoffered to sources and by sources to target. FIG. 4 shows calls admittedby target, and calls rejected with REL messages with ACL1 and ACL2.

[0110] The results shown in FIGS. 5 and 6 were obtained using the sametraffic values and network layout as for the first set of results, butthe second method of ACC was used instead. Also, an increase factor of1.03 as explained previously was assumed. FIG. 5 shows calls offered tosources and by sources to target. FIG. 6 shows calls admitted by target,and calls rejected with REL messages with ACL1 and ACL2.

[0111]FIGS. 3 and 5 show as a dashed line, the total number of calls persecond offered to all source exchanges . The solid line shows calls persecond offered to the target exchange by all source exchanges withautomatic congestion control according to the respective first or secondmethod operating.

[0112]FIGS. 4 and 6 show as dashed lines the call admittance rated ofthe target exchange with the first and second method of ACC operatingrespectively. AC1's which are the rate of call releases with ACL 1parameter are given by the solid spikes at 61 seconds. AC2's which arethe rate of call releases with ACL 2 parameter are given by the solidspikes at 61 seconds and 181 seconds. The target exchange is assumed toonly release calls under failure conditions, i.e. acting like aninternet access switch.

[0113] It will be seen from these results that both methods work well.In particular, as can be seen from the Figures, the methods reactquickly to a sudden onset of overload; they both keep the target justunder an overloaded state during the duration of high offered traffic atthe source; and, they do not allow the target to oscillate into and outof an overloaded state.

[0114] It will be seen that the preferred methods of ACC allow: themeasurement of call rates from the source accepted by the target node,and its use in modifying the leaky bucket rate for call restriction fromsource to target; the measurement of call rate offered to the source forthe target, and its use to determine when to lift the call restriction;and, adaptation of the leaky bucket restriction rate to changes oftarget capacity caused by modification of the target node or changes inthe network.

1. A method of suppressing overload of a first node in atelecommunications network by the steps of a second node: receiving asignal indicating that a call directed from the second node to the firstnode has been rejected and in response restricting the rate oftransmission of calls from the second node to the first node to apredetermined level, and monitoring duration through a predeterminedtime period wherein if a further signal indicating that a call directedfrom the second node to the first node is received during thepredetermined time period, the rate of transmission of calls from thesecond node to the first is restricted further to a further reducedpredetermined level and duration through a further predetermined periodis monitored.
 2. A method according to claim 1 in which the or eachpredetermined level of restriction is selected dependent upon themeasured rate of calls (D_(measured)) from the second node accepted bythe first node.
 3. A method according to claim 2, in which the measuredrate of calls successfully transmitted is determined as the number ofcalls offered to the first node from the second node minus the number ofrejected calls in a time interval.
 4. A method according to claim 1, inwhich the or each predetermined level of restriction is dependent onwhether the signal indicating rejection of a call indicates severeoverload or moderate overload.
 5. A method according to claim 1, inwhich the steps of restricting and monitoring are repeated until nosignal indicating that a call directed from the second node to the firstnode has been rejected is received during the latest predeterminedperiod.
 6. A method according to claim 5, in which if no signalsindicating that a call directed from the second node to the first nodehas been rejected is received during the latest predetermined period areduced level of restriction is applied, and duration through a furtherpredetermined period is monitored.
 7. A method according to claim 6, inwhich the level of restriction is reduced by increasing allowed callrate by a predetermined factor in the range 1.01 to 1.07.
 8. A methodaccording to claim 7, in which the predetermined factor is, or is about,1.03.
 9. A method according to claim 6, in which the step of reducingthe level of restriction is repeated after each predetermined timeperiod in which no signal indicating that a call directed from thesecond node to the first node has been rejected is received.
 10. Amethod according to claim 1 in which all the restrictions are removeddependent on the call rate (O_(new)) of calls offered to the second nodefor the first node being measured as becoming sufficiently low.
 11. Amethod according to claim 1 in which the rate of calls (D_(measured))accepted by the first node from the second node and rate of calls(O_(new)) offered to the second node for the first node are measuredcontinually or regularly.
 12. A method according to claim 1, in whichthe rate of calls (D_(measured)) accepted by the first node from thesecond node and the rate of calls offered to the second node for thefirst node are measured from receipt of the signal indicating that acall from the second node to the first node has been rejected, untilrestriction(s) are lifted.
 13. A method according to claim 1 in which,upon removal of the restrictions on the rate of transmission of callsfrom the second node to the first node, the latest level of restrictionwhich was applied is stored in a memory for reuse as the predeterminedlevel to be applied should overload reoccur in the future.
 14. Atelecommunications network comprising a first node and a second node,the second node comprising receiving means operative to receive a signalindicating that a call directed from the second node to the first nodehas been rejected, and restricting means operative in response to bothrestrict the rate of transmission of calls from the second node to thefirst node to a predetermined level and start its timer to monitorduration through a predetermined period, wherein, in use, if a furthersignal indicating that a call directed from the second node is receivedby the receiving means during the predetermined period being measured bythe timer, the restricting means reduces the rate of transmission ofcalls from the second node to the first node to a further predeterminedlevel and restarts the timer.
 15. A telephone network according to claim14, in which the restricting means is operative to repeat the steps ofrestricting and monitoring until no signal indicating that a calldirected from the second node to the first node has been rejected isreceived during the latest predetermined period.
 16. A telephone networkaccording to claim 14 in which the first node and second node aretelephone exchanges.
 17. A telephone network according to claim 16, inwhich the first node and second node are telephone exchanges connectedby switch circuitry and trunk lines.
 18. A telephone network accordingto claim 14, in which the first node is connected to a plurality ofsecond nodes, each operative to receive a signal that a call directedfrom itself to the first node has been rejected and operative inresponse to both restrict the rate of transmission of calls from itselfto the first node.
 19. A telecommunications apparatus comprisingreceiving means operative to receive a signal indicating that a callsent from said apparatus has been rejected, the apparatus comprisingrestricting means operative in response to restrict the rate of callssent out and start its timer to monitor duration through a predeterminedperiod, wherein in use, if a further signal indicating that a call sentfrom said apparatus has been rejected is received by said receivingmeans during the predetermined period measured by the timer, therestricting means further reduces the rate of calls sent out.
 20. Atelecommunications apparatus according to claim 19 which is a telephoneexchange.
 21. A computer program loadable onto telecommunicationsapparatus in a telecommunications network which when run executes themethod according to claim 1.